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Amendments to the Drawings 

The attached sheets of drawings include changes to Fig. 4. These sheets replace the 
original sheets of drawings. 

Attachment: Four replacement sheets 
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Remarks 

Applicants respectfully request reconsideration of the present application in view of the 
foregoing amendments and the following remarks. Claims 1-17 are pending in the application. 
Claims 1-17 are rejected. No claims have been allowed. Claims 1, 10, and 13 are independent. 
Claims 1,5, and 14 have been amended to clarify claim language. No new matter has been 
added. 

Cited Art 

The Action cites U.S. Pat. No. 6,560,720 to Chirashnya et al. ("Chirashnya"); 
U.S. Pat. No. 7,013,482 to Krumei ("Krumel"); Kim et al., "Design and Implementation of 
Home Network Systems Using UPnP Middleware for Networked Appliances", IEEE 
Transactions on Consumer Electronics, Volume 48, Issue 4, Nov 2002, pages 963-972 ("Kim"); 
Dugan et al "Design of Interfaces for Power Systems Analysis Components", Power Engineering 
Society Summer Meeting, Volume 2, 18-22, Pages 852-857, July 1999 ("Dugan"). 

Informalities in the Specification 

The Action objects to the disclosure, pointing to various alleged informalities in the 
specification. With respect to the "hyperlinks" on pages 1,5, and 12, Applicants note that 
inclusion of the hyperlinks was not intended as incorporation by reference. In order to expedite 
examination, however, Applicants have amended the specification to remove reference to these 
hyperlinks. 

With respect to the typographical errors of pages 14 and 17, Applicants have amended 
the specification to correct these errors. No new matter is added by these amendments. 

Claim Rejections - 35 USC § 112 

The Action rejects claims 1-9 and 14 under 35 USC § 1 12, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. 
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The Action rejects claim 1 for not specifying "what happens when the action request does 
not match an action out of the set of actions specified in the description," [Action, at page 4, 
para. 13.] Applicants have hence amended claim 1 to recite: 

in response to receiving an action request per the device connectivity 
protocol, validating to which action out of the set of actions specified in the 
description the action request matches; 

upon validating an action to which the action request matches, performing 
a default behavior consistent with the description. 

Applicants believe that the amended claim language addresses the rejection and is not indefinite 
and thus satisfies 35 USC § 112. 

The Action also rejects claim 14 for not specifying "what happens when the user- 
provided action behavior is not hooked for action," respectively. [Action, at page 5, para. 16.] 
However, Applicants respectfully disagree with the judgment of the Action that this language is 
indefinite. In particular, Applicants note that claim 13, from which claim 14 depends, recites: 

program code for performing a default behavior producing a response for 
the action consistent with the data format specified in the description. 

Claim 13 is then amended by claim 14 to also recite the language at question in the rejection, 

namely: 

program code operating in a case that a user-provided action behavior 
implementation is presently hooked for the action to invoke the user-provided 
action behavior implementation in place of the default behavior. 

Applicants note then that claim 13 already provides language reciting program code for 
performing a default behavior in response to the action, while claim 14 adds language reciting 
program code which invokes "user-provided action behavior" instead of the default behavior in 
the case that the user-provided action behavior is hooked. Thus, in the case that the user- 
provided action behavior is not hooked, the default behavior, already recited in claim 13, would 
be performed. Thus, Applicants believe that the claim language in its current condition is not 
indefinite and satisfies 35 USC § 1 12. 

The Action additionally rejects claim 5 alleging that the original language "of some 
number fewer than all of the set of actions" is a relative term that renders the claim indefinite. 
Applicants have amended the claim to read "of at least one action out of the set of actions but not 
every action out of the set of actions." The Action also rejects claim 14 alleging that the original 
language "any number of the set of actions" is a relative term that renders the claim indefinite. 
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Applicants have amended the claim to read "one or more actions out of the set of actions." 
Applicants believe that the amended claim language addresses the rejections and thus the claims 
are not indefinite and thus satisfy 35 USC § 1 12. 

Applicants believe that, through the amendments detailed above, claims 1,5, and 14, 
satisfy the requirements of 35 USC § 1 12. Applicants request that the rejection of these claims 
under 35 USC § 1 12, as well as the rejection of dependent claims 2-4 and 6-9, be withdrawn. 

Claims Rejections - 35 USC § 102 

The Action rejects claims 1-5, 13-16 under 35 USC § 102(a) as being anticipated by Kim. 
For a 102(a) rejection to be proper, the cited art must show each and every element as set forth in 
a claim. (See MPEP § 2131.01.) However, the cited art does not describe each and every 
element. Accordingly, applicants request that the rejection be withdrawn. 



Claim 1 recites, in part: 

processing a description of a device to be emulated in the device 
connectivity protocol, the description specifying a set of actions of the device; 

upon validating an action to which the action request matches, performing 
a default behavior consistent with the description. 

For example, the Application, describes examples of device emulation: 

The generic device emulator effectively provides an implementation of the 
emulated device as it would operate within the UPnP™ protocol. The emulated 
device can be any device that can operate in the UPnP™ architecture (i.e., any 
UPnP™ -compliant device). Alternative embodiments of the generic device 
emulator for other device connectivity or communication protocols can provide 
generic emulation of devices for such protocols. 

The generic device emulator 210 emulates the behaviors of the emulated 
device within UPnP™ based on the UPnP™ description of the device .... Given 
the device and service descriptions 220-221 of any UPnP™ device, the generic 
device emulator 210 emulates behaviors implementing the description within 
UPnP™. . . . 

In the control phase, the generic device emulator 210 implements default 
behaviors for the actions specified in the emulated device's service description 
document(s) 22 1 . The generic device emulator 21 0 receives action invocation 
messages (SOAP commands) from control points and validates these messages 
against the emulated device 's service description. Upon validation, the generic 
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device emulator 210 provides a default response to the action invocation, which 
response conforms to the data format and types specified in the service 
description for the action. For example, if the response to the action specified in 
the service description is to return an integer value, the default behavior simply 
returns a default integer value (e.g., a zero). 

[Application, at page 13, line 2, to page 14, line 2.] 

Kim 's home server describes the traditional invocation of actions by devices, resulting in 

updated status variables, which does not teach or suggest "performing a default behavior 

consistent" with a "description of a device to be emulated" as recited in claim L In its rejection 

of this language of claim 1, the Action cites to page 965, column 1, para. 4 and Figure 2 of Kim. 

The cited portion, however, describes invocation of actions by appliances, not default behavior: 

In the applicants section of the home server program display, simple 
information about each monitored appliance (the state variables) is displayed at 
the top. When the user invokes an action service using the action item in the 
device control frame, a message is sent to invoke the action. When successful, 
the updated state variables are displayed on the home server. 

[Kim, at page 965, column 1, para. 4.] In this section, Kim makes clear that the action is being 

performed by an actual UPnP-compatible appliance, and is not performed in order to emulate a 

device. In particular, the cited portion of Kim describes "updated state variables" which indicate 

the changing of an appliance state. This teaches away from the performance of a "default 

behavior" which would not require state variables to update. Figure 2 likewise discusses updated 

variables in its "Action Invocation loop," which was also cited in the rejection of claim 1. 

Furthermore, Kim 's description of information about appliances which are currently 

attached to a home network system does not teach or suggest "a description of a device to be 

emulated" as recited in claim 1. At page 965, column 1, para. 2, cited in the Action in the 

rejection of this language of claim 1, Kim describes the discovery of UPnP-compatible 

appliances which are connected to a home network system: 

When a UPnP-compatible appliance is found, a display icon of the 
appliance and its name appear in the tree view on the left side of the home server 
and home browser programs. The user receives information about the services 
and actions of the home appliance by double-clicking on the tree view. When an 
action service is invoked the information of the arguments of the appliances in 
operation is displayed. 

Thus, as Kim describes, the information cited in the Action describes appliances which are 
currently connected to the home network system. Because this information is about appliances 
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which are currently attached, this information does not teach or suggest, and in fact teaches away 
from, "a description of a device to be emulated" which is recited in claim 1. 

For at least these reasons, Kim cannot teach or suggest each and every element in 
claim 1. Thus, the rejection of claim 1 over Kim is improper. Applicants therefore request that 
the rejection of claim 1, and of dependent claims 2-5, be withdrawn and claims 1-5 be allowed. 

Claim 13 

Claim 13 recites, in part: 

Computer-readable media having stored thereon a software framework of 
a generic device emulator for execution on a computer to provide emulation of an 
operation of a device within a device connectivity architecture consistent with a 
textual description of the device, ... the generic device emulator comprising: 

program code for performing a default behavior producing a response for 
the action consistent with the data format specified in the description. 

In its rejection of the quoted language in claim 13, the Action cites to the same portions 

of Kim as were discussed above with respect to claim 1. Thus, for at least the reasons discussed 

above with respect to claim 1, Kim cannot teach or suggest each and every element in claim 13. 

The rejection of claim 13 over Kim is improper. Applicants therefore request that the rejection 

of claim 13, and of dependent claims 14-16, be withdrawn and claims 13-16 be allowed. 

Claim Rejections - 35 USC§ 103 
The Action rejects claims 6-12 and 17 under 35 USC 103(a) as being unpatentable over a 
variety of references. In particular, the Action rejects independent claim 10 under 35 USC 
103(a) as being unpatentable over Krumel, in view of Kim and Dugan. To establish a prima 
facie case of obviousness, three basic criteria must be met. First, there must be some suggestion 
or motivation, either in the references themselves or in the knowledge generally available to one 
of ordinary skill in the art, to modify the reference or to combine reference teachings. Second, 
there must be a reasonable expectation of success. Finally, the prior art reference (or references 
when combined) must teach or suggest all the claim limitations. (MPEP § 2142.) 

Claim 10 

Claim 10 recites: 
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A method of emulating devices in a device connectivity protocol, the 
method comprising: 

reading a defect configuration representing in a tagged text format at least 
one defect behavior to be applied to a type of packet transmitted from an emulated 
device per the device connectivity protocol; 

upon producing a packet of a type for which a defect behavior is 
represented in the defect configuration, applying the defect behavior to the 
packet; and 

transmitting the packet as modified by applying the defect behavior. 

For example, the Application describes the actions of a "defect callback handler;" 

All the packets before being sent out on the socket are consulted with the 
Defect Callback Handler object 342. The user can implement methods to inject a 
defect or defects into the packets. Tins feature is extremely useful in testing 
control points. Each method will inject a defect or defects into a particular 
message type. The user creates a defect behavior type by specifying a set of such 
methods using the defect configuration file 350. More information on specifying 
the defect types is detailed below. If no defect behavior is specified, the generic 
device emulator will emulate a perfect working device that is compliant with the 
UPnP™ Architecture 100. 

[Application, at page 18, lines 10-17; emphasis added.] A particular example of the usefulness 

of the addition of defects, as well as a type of defect, is shown at page 14, line 27 to page 15, 



The generic device emulator 210 further provides a mechanism (described 
more fully below) for the vendor to define defective behaviors, which can be 
useful for testing control points 110-111 (Figure 1). The defective behaviors are 
defined using XML format statements in a textual configuration file, which 
describe defect filters to be applied to the messages generated by the generic 
device emulator for the emulated device. For example, a defect filter can be 
defined to have the generic device emulator 210 strip off a leading '* ' character 
from headers of SOAP messages sent for the emulated device. 

[Emphasis added.] 

Krumel's filtering criteria are used for the removal of bad packets, and thus do not teach 

or describe "at least one defect behavior to be applied to a type of packet " which is then 

transmitted after "applying [ofj the defect behavior to the packet [s] " as recited in claim 10. 

Krumel describes "[mjethods and systems for firewall/data protection" which work by 

"filtering] data packets in real time." [Krumel, at Abstract.] Krumel does this by applying 

various "filtering criteria" to packets: 

If a packet of data fails to meet the filtering criteria, then it is not allowed 
to pass as a valid packet and is "junked." 
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[Krumel, at column 4, line 66 to column 5, line 1 .] Thus, Kramers filtering criteria are used in 

order to locate and remove packets. Krumel emphasizes its use of this information in its use of 

the term "failed" to describe packets which satisfy the criteria: 

In preferred embodiments, if any one or more of the performed filtering 
rules indicates that the packet should be failed (or not allowed to pass as a valid 
packet), then the output of aggregator 24 is a fail; otherwise, the packet is allowed 
and the output of aggregator 24 is a pass. 

[Krumel, at column 6, lines 26-30.] 

Thus, because Krumel' s filtering criteria is directed toward the removal of packets, it 
teaches against the desirability of defining defects to be applied to packets. And therefore, it 
cannot teach or suggest "a defect configuration representing ... at least one defect behavior to be 
applied to a type of packet" as well as "applying the defect behavior to the packet" and 
"transmitting the packet as modified by applying the defect behavior" as recited in claim 10. For 
at least these reasons, Krumel does not teach or suggest the above-quoted language of claim 10. 
Furthermore, Applicants do not find such disclosure in either Kim or Dugan. Thus, the rejection 
of claim 10 over Krumel in view of Kim and Dugan is improper. Applicants request that the 
rejection of claim 10 be withdrawn. 

Applicants also request that the rejections of claims 1 1 and 12, each of which depend 
from claim 10, be withdrawn. Claim 1 1 is rejected over identical art as claim 10, and claim 12 is 
additionally rejected over Chirashnya, from which Applicants do not find additional disclosure 
for the above-quoted language of claim 10. Thus, Applicants request that claims 10-12 be 
allowed. 

Finally, the Action rejects claims 6-9 and 17 under 35 USC 103(a) as being unpatentable 
over Kim et al as applied to claims 1 and 13, respectively, and further in view of Chirashnya 
(claims 6, 8, and 9), Chirashnya and Krumel (claim 7), or Krumel and Dugan (claim 17). 
Because Applicants do not find additional disclosure for the above-quoted language of claims 1 
and 13 in either Chirashnya, Krumel, or Dugan, Applicants respectfully submit that, for at least 
the reasons discussed above with respect to claims 1 and 13, the rejections of claims 6-9 and 17 
are improper. Applicants request that the rejections of claims 6-9 and 17 be withdrawn and that 
the claims be allowed. 

Request For Interview 
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If any issues remain in light of these remarks and amendments, the Examiner is formally 
requested to contact the undersigned attorney to arrange a telephonic interview. It is believed 
that a brief discussion of the merits of the present application may expedite prosecution. 
Applicants submit the preceding formal Amendment and the above remarks so that the Examiner 
may fully evaluate Applicants' position, thereby enabling the interview to be more focused. 

This request is being submitted under MPEP § 713.01, which indicates that an 
interview may be arranged in advance by a written request. 

Conclusion 

The claims in their present form should be allowable. Such action is respectfully 
requested. 



Respectfully submitted, 



KLARQUIST SPARKMAN, LLP 



One World Trade Center, Suite 1600 
121 S.W. Salmon Street 
Portland, Oregon 97204 
Telephone: (503) 595-5300 
Facsimile: (503)595-5301 



By 




Registration No. 37,759 
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